Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-181 < prev next >

Wrap

Text File | 1988-12-01 | 12.6 KB | 525 lines

To: Linda at ISIF Cc: JHaverty at BBNG IEN-181 Van Gateway: Some Routing and Performance Issues Jack Haverty Bolt Beranek and Newman Inc. May 1981 IEN-181 Bolt Beranek and Newman Inc. Jack Haverty The VAN gateway is a new facility currently under development for the internet community. Its intended purpose is to allow interconnection of the ARPANET and therefore the Internet with Telenet, but it also introduces a new mechanism whose failure or misuse can seriously affect the system. The key problem with use of the VAN gateway is to allow and encourage using it for legitimate purposes, while preventing utilization by unauthorized users or as a result of a software or hardware failure in the networks involved. There are two aspects to this problem. The first control on the gateway usage must be to assure that the packets being handled are legitimate, in that they are associated with authorized users. This is a specific example of the need for mechanisms which have been discussed at various times as "restricted routing" mechanisms. The second control problem is to assure that the gateway is being used as intended, with a reasonable level of traffic for the function being performed. Even if packets are being processed for authorized users, it is possible for failures within the routing system or host software, for example, to cause packets to loop endlessly. Failures of the network protocols could similarly cause duplicate packets to be sent needlessly. -1- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty In both cases, the concern results from the highly visible impact which use of Telenet incurs, since charges are computed on a per-packet basis. However, the same issues are inherent in the Catenet itself, in that misuse of the network consumes resources which are then unavailable for legitimate use. Thus the problem of managing use of the gateway is most critical for the VAN gateway, but applies as well to all gateways, and in fact to any shared resource. In the initial implementation of the VAN gateway, resource management is being provided by use of tables which enumerate the authorized users of the gateway. These users are simply the addresses of the hosts, both on the ARPANET (Catenet) side and on the Telenet side, which will be acceptable as valid source and destination addresses of packets which transit the gateway. All other packets which are received by the gateway will be discarded. In the internet architecture, the Telenet side of the gateway appears as a single network to the internet mechanisms. The gateway contains a table which maps artificial host addresses on that network into real 14-digit Telenet/X.25 addresses, in much the same way as other networks convert internet addresses into addresses for their particular attached network. X.25 virtual circuits are only permitted between the gateway and X.25 -2- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty hosts which are present in this translation table, which effectively defines the set of authorized gateway users in the X.25 community. No similar table is necessary for translation of addresses on the ARPANET side of the gateway, since this translation is well defined by the internet protocol. Without any additional mechanisms, this would permit any ARPANET host to use the VAN gateway. In addition, since gateways to other networks are simply ARPANET hosts, this would permit any host on the Catenet to use the VAN gateway. To restrict the user community of the VAN gateway, a second table is provided, which enumerates all internet addresses which are acceptable as sources or destinations on the ARPANET side of the gateway. Each internet datagram which arrives from the ARPANET or Telenet is checked to assure that the source and destination addresses in the internet header are listed in one of the two tables which define the set of hosts which are permitted to use the VAN gateway. The table entries will be set up directly by DARPA. In selecting the set of valid hosts, the reliability of the data presented to the gateway should be considered. -3- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty In particular, we note that there is a significant difference in the addresses presented at the gateway in the internet header of each packet. If such an address is in fact on the ARPANET, the gateway can verify it by comparison with the address supplied by the IMP in the ARPANET leader of the packet. For packets sent to the ARPANET, one can similarly expect the IMP subnet to deliver the packet to the host specified in the ARPANET leader. If the address of a packet handled by the gateway is on another component network of the Catenet, the packet is necessarily handled through one or more gateways. The internet structure permits gateways to freely enter the system. Gateways are in general under the control of the organization which owns them and/or the attached network. Gateways in general do not check the addresses in the internet headers of packets which they process, so it is possible for malfunctioning hardware or software to emit packets with incorrect addresses. If such addresses happen to be present in the VAN gateway tables, these packets will be processed by the VAN gateway. The impact of this situation on the policy for allowing use of the VAN gateway is that hosts on networks other than the ARPANET are to be considered somewhat less reliable in terms of enforcement of the usage policy. The mechanisms in the initial -4- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty VAN gateway implementation will provide some degree of control over the use of the gateway, but these mechanisms are not to be considered appropriate or complete in the general sense, and they are not proof against failures. These mechanisms are intended only as an interim measure. We suggest that further development work on the internet gateway system, of which the VAN gateway is a component, should address the problems of resource control at the internet system level. Any mechanism which restricts the usage of a gateway must be designed in conjunction with other network mechanisms, such as routing, flow control, load sharing, and error control. As an example, we can consider a hypothetical configuration in which two VAN gateways are connected to Telenet, one from ARPANET, and the other from SATNET, to support traffic between Telenet users and hosts on ARPANET or SATNET. Only these user/hosts would be listed in the VAN gateway tables. Since the VAN gateways are participants in the internet routing mechanisms, failure of the gateway between ARPANET and SATNET would cause the system to recognize the path through TELENET, as a transit network, as a viable route for ARPANET- SATNET traffic. However, this traffic would be discarded at the VAN gateway because the addresses are not listed in its tables. -5- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty This scenario will be avoided by preventing the two VAN gateways from being "neighbors" for routing purposes, which is acceptable only in restricted configurations. The general problem results from the usage restrictions at the VAN gateway, which makes the path a valid route for one class of packets, but invalid for other classes. The current routing mechanism cannot handle this situation. In addition, the effect of the usage restrictions on future mechanisms for handling partitioned networks, and load sharing of gateway paths, must be investigated. We have two mechanisms to propose for consideration as mechanisms to attack this problem. The first is a resource control model which is a result of the TIP Login work. The second involves the use of performance models, which monitor use of resources to determine if unexpected behavior occurs. These two mechanisms can be introduced to work more effectively in the VAN gateway problem. The architecture for the TIP Login system identifies several abstract modules which interact to implement the resource control functions. A "Control Point" is the module which directly controls the use of a resource. It is responsible for detecting an attempt to use some resource, collecting such information -6- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty which identifies who is trying to use the resource and what they are trying to do, and then permitting or denying use of the resource. The decision concerning whether or not a particular usage is allowed is made by a "Decision Module." This module takes the information supplied by the Control Point, and applies the algorithm which defines the resource usage policy. Typically, and particularly in the Tip Login case, the Decision Module will obtain more information about the particular user and/or resource involved in the decision, by using a distributed database system. In the TIP Login system, the Control Point is at each TIP. Decision Modules are located in special-purpose hosts. The database system is present in those hosts as well as on larger database-maintenance hosts, where tools to manipulate and modify the database exist. Typically the Decision Module identifies the particular individual attempting to use a TIP, and retrieves a record of information specific to that individual, which defines his authorizations (or lack thereof). Much of this mechanism should prove to be useful as a basis for control of gateways as well. In such a system, the control points would be at the gateways. Decision Modules might also be at the gateways, if decisions must be made on each packet. Decisions might be based on source or destination addresses, or -7- IEN-181 Bolt Beranek and Newman Inc. Jack Haverty on the identify of the individual responsible for the packet. We suggest that this approach be considered for further research. A problem which is not being addressed currently is the second control problem mentioned earlier, namely the monitoring of the use of some resource by an authorized user, to guarantee that the resource is being used as intended. In the VAN gateway case, for example, a malfunctioning TCP might cause many unnecessary packets to be handled, but since they are associated with authorized addresses, no control is applied. In addition to the obvious cost and performance penalties, lack of monitoring precludes the use of policies which grant limited use of resources to, for example, allow some users to handle only low- throughput traffic, or low priority traffic. We believe that the use of performance models, embedded within the gateways and for hosts, is a promising direction for attacking this problem. Limitations of the current LSI-11 implementation of the VAN gateway are likely to preclude any significant testing of these approaches. We have been pursuing these ideas as research issues, which have surfaced during the current implementation efforts. -8-